昨天，你終於讓那個最強的工程師「閒下來」——不讓他滿載，反而讓整體的交付速度提升了。

但今天早上的高層會議，讓你面對一個更棘手的現實。

當 CEO 說「這十個專案全部都是 P0」，你敢不敢當場說「不可能」？

場景：所有人都說 Urgent

會議室裡，CEO 翻開簡報：「這是董事會要的 Q3 Roadmap，AI Agent 產品、BI 平台升級、數據治理專案、客戶分析儀表板、內部知識庫、API 效能優化——這十個專案，全部都要在三個月內交付。」

業務副總接話：「客戶已經在等 BI 平台了，再不做他們會跳槽。」

產品長補充：「AI Agent 是董事會承諾的旗艦產品，延誤不得。」

財務長說：「數據治理是合規要求，這個月底前要有初步成果。」

CEO 轉頭看你：「團隊準備好了嗎？這些全部都是 P0，全部優先。」

你看著會議桌上攤開的十份專案規劃，腦中浮現的畫面是：你的三個團隊——Data、Platform、AI——加起來 18 個人，現在手上已經有五個進行中的專案。

如果這十個都接下來，每個人平均要同時處理 0.8 個專案。

聽起來很合理，對吧？

錯，大錯特錯。

兩難：全部接？還是拒絕？

散會後，你回到辦公室，盯著牆上的白板發呆。兩條路擺在你面前：

如果是你，你敢不敢在 CEO 面前說「這十個不可能同時做，我們只能選三個」？

先別往下看

認真想三十秒。

你會選 A 還是 B？

為什麼？

翻牌：同時追十隻兔子，你一隻都抓不到

正確答案是 B。

但這也是最需要勇氣的選擇。當所有人都在會議室裡看著你，當業務說「客戶會流失」，當 CEO 說「董事會在等」的時候，你要怎麼說「不」？

因為《鳳凰專案》告訴你一個相反直覺的真相：

同時做的事情越多，每件事前進的速度就越慢。

這不是工作態度問題，也不是團隊努不努力的問題，而是純粹的數學問題。

這就叫 WIP（Work In Progress，在製品）的隱形損耗。

在實體工廠裡，這件事非常直觀：一條生產線上如果堆了一百個半成品，每個半成品都在搶機台、搶人工、搶時間，結果就是沒有一項產品可以完工，完成品的產出速度跌到谷底。

在軟體開發裡，情況一模一樣——而且更隱形，因為我們看不見「半成品堆在產線上」的實體景象。

當一個工程師手上同時被交辦三個專案，他的一天會變成這樣：

09:00-10:00 專案 A 的前置開發
10:00-10:30 每日站會 + 回覆 Slack 訊息（Context Switch #1）
10:30-11:30 專案 B 的資料庫 Migration
11:30-12:00 專案 C 的 Code Review
12:00-13:00 午餐 + 跨部門溝通會議
13:00-14:00 回到專案 A（Context Switch #2，需要花 15 分鐘重新回想「我剛才做到哪」）
14:00-15:00 專案 B 的測試環境掛了，緊急除錯（Context Switch #3）
15:00-16:00 專案 A 的產品功能討論會
16:00-17:00 回到專案 C（Context Switch #4，重新載入腦海中的程式上下文）
17:00-18:00 專案 A 的緊急修補（Hotfix）

八個小時的工作時間裡，真正專注寫 Code 的時間只有三個小時。

其他五個小時，全在「切換任務」。

這就是 Context Switching（上下文切換）的隱形稅：每次切換任務，大腦要花 10–25 分鐘才能重新進入狀態，重新載入「這個專案的架構、我上次寫到哪裡、我為什麼這樣設計」。

軟體工程界流傳一組經典的估算（源自 Gerald Weinberg 在《Quality Software Management》中提出的任務切換成本損耗概念）：

• 同時做 1 個專案：有效產能為 100%。
• 同時做 2 個專案：有效產能掉到 40% × 2 = \mathbf{80%}（20% 被切換損耗）。
• 同時做 3 個專案：有效產能掉到 20% × 3 = \mathbf{60%}（40% 被切換損耗）。
• 同時做 5 個專案：有效產能掉到 5% × 5 = \mathbf{25%}（75% 被切換損耗）。

當你的團隊同時背負十個專案，真正的有效產能可能只剩下不到 15%。

你以為是在「平行處理」，其實是在「平行延宕」。

《鳳凰專案》裡 Erik 給 Bill 的核心建議之一就是：

Stop Starting, Start Finishing.（停止開始，專注完成）

這也是 Kanban（看板方法）的核心思想：限制 WIP（Limit Work In Progress）。

不是「同時做越多越好」，而是「同時做越少越快」。

少即是多。

如果有 AI Agent：把過載變成紅燈

問題是，怎麼說服 CEO？

你說「Context Switch 成本很高」，CEO 說「那是執行力與時間管理問題」。

你說「同時做太多會慢」，業務副總說「那是因為工程師人不夠多」。

你需要數據，讓「系統過載」變成看得見的警訊紅燈。

這時候，AI Agent 可以幫你做一件事：即時顯示每個人手上真正進行的 WIP、Context Switch 頻率、完成速度的下降趨勢，讓「過載」不再是抽象的感覺，而是可以量測的紅燈。

graph TD
    A[Jira tickets] --> E[Agent 分析]
    B[Git commits] --> E
    C[Calendar events] --> E
    D[Code review activity] --> E
    E --> F[計算每人實際 WIP]
    F --> G{WIP > 3?}
    G -->|Yes| H[標示紅燈:<br/>此人已過載]
    G -->|No| I[標示綠燈:<br/>此人有餘裕]
    E --> J[計算 context switch 頻率]
    J --> K{每天切換 > 5 次?}
    K -->|Yes| L[警告:切換成本過高]
    E --> M[計算完成速度:ticket 從 doing 到 done<br/>的平均時間]
    M --> N[趨勢圖:<br/>WIP 上升時<br/>完成時間如何變化]
    H --> O[產出「過載儀表板」]
    L --> O
    N --> O
    O --> P[向 CEO 展示:<br/>接這十個案子會發生什麼]

Agent 做的事情很直接：

1. 抓取每個人手上「In Progress」的 Ticket 數量，標出已經超過 3 個的過載警戒線。
2. 從 Git Commit、Code Review 記錄以及會議日曆算出「一天內切換幾次任務」。
3. 計算「完成速度」：追蹤單張 Ticket 從 Doing 到 Done 平均花費多久。
4. 將這些數據製作成趨勢圖：當 WIP 從 2 增加到 5 時，完成時間是不是從 4 天拉長到了 18 天？

隨後，Agent 會產出一份量化報告：

團隊產能與 WIP 評估報告（過去 2 個月）

📊 當前現況

• 團隊總人數：18 人
• 進行中專案：5 個
• WIP Tickets 總數：82 張
• 平均個人 WIP 負載：4.6 張 ⚠️ （建議門檻 < 3 張）

⏳ WIP 與完成速度趨勢

• WIP \le 2：平均單張 Ticket 完成時間為 6 天。
• WIP = 3：平均單張 Ticket 完成時間為 11 天。
• WIP \ge 4：平均單張 Ticket 完成時間為 22 天 🔴 （呈指數級拉長）

🔄 上下文切換（Context Switching）損耗

• 團隊平均每日切換任務：7.2 次。
• 任務切換損耗（Switching Tax）時間比率：52% ⚠️ （超過一半的工作時間花在切換上下文）

🔮 專案推演與未來預估

方案一：硬追 10 個新專案（不限制 WIP）

• 預估 WIP Tickets 總數：150+ 張。
• 預估個人 WIP 負載：8.3 張 🚨。
• 預估單張 Ticket 完成時間：45+ 天。
• 預估三個月內上線專案數：0 - 1 個。

方案二：限制 WIP 並梯次推進（推薦方案）

1. 先集中火力完成目前 5 個專案中進度最領先的 2 個。
2. 自 10 個新專案中挑選 3 個最高優先級的項目啟動，其餘 7 個排入 Backlog 隊列。
3. 預期效果：每 6 週可穩定完成並交付 2 - 3 個專案，實現持續交付。

這時候，你拿著這份報告走到 CEO 辦公室。

你不是懦弱地說「我們做不到」，而是專業地向他呈現決策的代價：

「如果十個專案都同時接，三個月後一個都不會上線，董事會會看到零交付。但如果我們限制同時進行的工作量，先做這三個最關鍵的，兩個月就能交付前兩個，三個月交付第三個，剩下的七個在 Q4 接力推進完成。您選哪個？」

這就是 2026 年的做法：用數據證明「少做才能多完成」，把感性的「不可能」變成理性的「預測模型」。

現場推演：那個什麼都沒上線的三個月

來看一個常見的情況（綜合改編，數字示意）。

想像一個 12 人的產品開發團隊，年初收到 10 個來自不同業務單位的「必須做」專案。團隊主管想讓所有人滿意，決定「全部都平行推進」。

三個月後，慘劇發生了：

• 10 個專案全部啟動，每個都分配了人力。
• 但沒有任何一個上線：有的完成度 80%，有的 30%，最慘的只有 5%。
• 團隊每天都在疲於奔命地救火、對齊、重新溝通需求（因為頻繁切換，每次重新動工都要重新回想上下文）。
• 業務單位全部不滿意：「你們說要做，為什麼三個月了還沒看到任何產出？」

第四個月，換了新主管，做了一件痛苦但正確的事：凍結 7 個專案，只留 3 個。

結果：

• 第一個半月完成 1 個專案（原本已完成 80% 的專案，集中火力兩週收尾上線）。
• 第二個月完成 2 個專案（原本進度 30% 的專案，在心無旁騖下迅速做完）。
• 第三個月解凍下一批，又順利完成了 2 個。

半年內穩定交付 5 個專案，遠比三個月內 0 個來得更有價值。

團隊工程師說：「我終於知道『少做反而更快』是什麼意思了。以前每天都在任務之間切換，腦袋根本無法專注。現在一次只做一件事，速度快到我自己都嚇一跳。」

這就是限制 WIP 的力量。

今日金句

「同時追十隻兔子，你一隻都抓不到。停止開始，開始完成。」

留給你的問題

你的團隊現在同時在進行幾件事？

如果把那個數字砍掉一半，真的會更慢嗎？

還是反而更快？

去算一下你的團隊現在的 WIP。如果每個人手上超過三件事，你就知道為什麼進度一直拖了。

明天，我們會面對一個更殘酷的決定：不只是排序，而是真的「凍結」一批專案——對某些人說「你的案子先停」。

你敢不敢？Day 15 見。